Method and apparatus for providing a specific user interface in a system for managing content

ABSTRACT

A method and apparatus for managing use of protected content by providing a specific user interface to an application program used to render the content. The method includes identifying a user interface description associated with content, building a specific user interface based on the user interface description, and replacing the standard user interface of an application program used to render the content with the specific user interface. The specific user interface can be unique to the user, unique to a Web site, or otherwise customized.

RELATED APPLICATION DATA

This application is a Continuation of application Ser. No. 13/019,445filed Feb. 2, 2011, now pending, which is a Continuation of applicationSer. No. 10/425,649 filed Apr. 30, 2003, now U.S. Pat. No. 7,913,095,which is a Continuation of application Ser. No. 10/046,670 filed Jan.16, 2002, now U.S. Pat. No. 7,743,259, which claims benefit of priorityto Provisional Application Ser. No. 60/261,803 filed on Jan. 17, 2001,now expired, and is a Continuation-in-Part of application Ser. No.09/649,841 filed Aug. 28, 2000, now U.S. Pat. No. 7,073,199, all ofwhich are incorporated by reference in their entirety herewith.

FIELD OF THE INVENTION

The invention relates to distribution of digital content, and moreparticularly, to a method and apparatus for facilitating distribution ofprotected documents displayed with the rendering engine of a standardapplication program, such as an Internet Web Browser.

BACKGROUND OF THE INVENTION

The Internet is a worldwide network of computers linked together byvarious hardware communication links all running a standard suite ofprotocols known as TCP/IP (transmission control protocol/Internetprotocol). The growth of the Internet over the last several years hasbeen explosive, fueled in the most part by the widespread use ofsoftware tools (known as “browsers”) which allow both HTML (hypertextmarkup language) viewing and HTTP (hypertext transfer protocol)navigation. Browsers allow a simple GUI (graphical user interface) to beused to communicate over the Internet. Browsers generally reside on thecomputer used to access content on the Internet, i.e. the clientcomputer. HTTP is a component on top of TCP/IP and provides users accessto documents of various formats using the standard page descriptionlanguage known as HTML and more recently XML (extensible markuplanguage) and XHTML (extensible hypertext markup language), areformulation of HTML into XML. The collection of servers on theInternet using HTML/HTTP has become known as the “World Wide Web” orsimply the “Web.”

Through HTML, XHTML, and interactive programming protocols, the authorof content is able to make the content available to others by placingthe content, in the form of a Web page, on an Internet Web server. Thenetwork path to the server is identified by a URL (Uniform ResourceLocator) and, generally, any client running a Web browser can access theWeb server by using the URL. A client computer running a browser canrequest a display of a Web page stored on a Web server by issuing a URLrequest through the Internet to the Web in a known manner.

Since the Web utilizes standard protocols and a standard renderingengine, i.e. the rendering engine of the browser, the Web has becomeubiquitous. One of the primary applications of the Web has beendistribution of content in the form of documents. A “document”, as theterm is used herein, is any unit of information subject to distributionor transfer, including but not limited to correspondence, books,magazines, journals, newspapers, other papers, software, photographs andother images, audio and video clips, and other multimedia presentations.A document may be embodied in printed form on paper, as digital data ona storage medium, or in any other known manner on a variety of media.

However, one of the most important issues impeding the widespreaddistribution of digital documents, i.e. documents in forms readable bycomputers, via electronic means, and the Internet in particular, is thecurrent lack of protection of the intellectual property rights ofcontent owners during the distribution and use of those digitaldocuments. Efforts to resolve this problem have been termed“Intellectual Property Rights Management” (“IPRM”), “Digital PropertyRights Management” (“DPRM”), “Intellectual Property Management” (“IPM”),“Rights Management” (“RM”), and “Electronic Copyright Management”(“ECM”), collectively referred to as “Digital rights management (DRM)”herein.

In the world of printed documents, a work created by an author isusually provided to a publisher, which formats and prints numerouscopies of the work. The copies are then sent by a distributor tobookstores or other retail outlets, from which the copies are purchasedby end users. While the low quality of copying and the high cost ofdistributing printed material have served as deterrents to unauthorizedcopying of most printed documents, it is far too easy to copy, modify,and redistribute unprotected digital documents. Accordingly, some methodof protecting digital documents is necessary to make it more difficultto copy and distribute them without authorization.

Unfortunately, it has been widely recognized that it is difficult toprevent, or even deter people from making unauthorized distributions ofelectronic documents within current general-purpose computing andcommunications systems such as personal computers, workstations, andother devices connected over communications networks, such as local areanetworks (LANs), intranets, and the Internet. Many attempts to providehardware-based solutions to prevent unauthorized copying have proven tobe unsuccessful. The proliferation of “broadband” communicationstechnologies (NII) will render it even more convenient to distributelarge documents electronically, including video files such as fulllength motion pictures, and thus will remove any remaining deterrents tounauthorized distribution of documents. Accordingly, DRM technologiesare becoming very useful.

Two basic schemes have been employed to attempt to solve the documentprotection problem: secure containers and trusted systems. A “securecontainer” (or simply an encrypted document) offers a way to keepdocument contents encrypted until a set of authorization conditions aremet and some copyright terms are honored (e.g., payment for use). Afterthe various conditions and terms are verified with the documentprovider, the document is released to the user in clear form. Commercialproducts such as Cryptolopes by IBM™ and by InterTrust's™ Digiboxes fallinto this category. Clearly, the secure container approach provides asolution to protecting the document during delivery over insecurechannels, but does not provide any mechanism to prevent legitimate usersfrom obtaining the clear document and then using and redistributing itin violation of content owners' intellectual property.

Cryptographic mechanisms are typically used to encrypt (or “encipher”)documents that are then distributed and stored publicly, and ultimatelyprivately deciphered, i.e. unencrypted, by authorized users. Thisprovides a basic form of protection during document delivery from adocument distributor to an authorized user over a public network, aswell as during document storage on an insecure medium.

In the “trusted system” approach, the entire system is responsible forpreventing unauthorized use and distribution of the document. Building atrusted system usually entails introducing new hardware such as a secureprocessor, secure storage and secure rendering devices. This alsorequires that all software applications that run on trusted systems becertified to be trusted. While building tamper-proof trusted systems isstill a real challenge to existing technologies, current market trendssuggest that open and untrusted systems such as PC's and workstationsusing browsers to access the Web, will be the dominant systems used toaccess copyrighted documents. In this sense, existing computingenvironments such as PC's and workstations equipped with popularoperating systems (e.g., Windows™, Linux™, and UNIX) and renderingapplications such as browsers are not trusted systems and cannot be madetrusted without significantly altering their architectures. Of course,alteration of the architecture defeats a primary purpose of the Web,i.e. flexibility and compatibility.

U.S. Pat. No. 5,715,403, the disclosure of which is incorporated hereinby reference, discloses a system for controlling the distribution ofdigital documents. Each rendering device has a repository associatedtherewith. Usage rights labels are associated with digital content. Thelabels include usage rights that specify a manner of use of the contentand any conditions precedent for exercising the manner of use. U.S. Pat.No. 5,052,040 discloses the use of a label prefixed to digital files sothat different users can have specific encryption capability and rightswith respect to the same file.

Two basic approaches have been taken to control the distribution ofdocuments over the Web. The first approach is the use of subscriptionbased services in which the user is only granted access to content afterpaying a subscription fee. However, once the subscription fee is paidand the document is rendered by the browser, the user can copy, print,and modify the document, i.e. all control of the document by thepublisher is lost.

The second approach is to utilize proprietary formats wherein thedocument can only be rendered by a select rendering engine that isobligated to enforce the publisher's rights. Of course, this approachrequires the use of a single proprietary format and loses the ability tocombine plural popular formats and the richness of content associatedtherewith. Further, this approach requires the user to use a proprietaryrendering application that must be obtained and installed on the user'scomputer and requires development of the rendering application for eachformat to be rendered in a secure manner. Further, the documents must begenerated or converted using non-standard tools.

Further, there are various known mechanisms by which functionality canbe added to a standard rendering engine, such as a Web browser. Forexample, an ActiveX control can be automatically downloaded and executedby a Web browser. ActiveX is a set of rules for how applications shouldshare information and ActiveX controls can be developed in a variety ofprogramming languages, including C, C++, Visual Basic, and Java.

An ActiveX control is similar to a Java applet. Unlike Java applets,however, ActiveX controls have full access to the Windows™ operatingsystem. Microsoft™ has developed a registration system so that browserscan identify and authenticate an ActiveX control before downloading it.Java applets can run on all platforms, whereas ActiveX controls arecurrently limited to Windows environments.

A scripting language called VBScript enables Web authors to embedinteractive elements in HTML documents to initiate a download andinstallation of ActiveX controls and other functions. Currently,Microsoft's Web browser, Internet Explorer™, supports Java, JavaScript,and ActiveX, whereas Netscape's Navigator™ browser supports only Javaand JavaScript, though its plug-ins can enable support of VBScript andActiveX. However, the availability of various plug-in and add-onsoftware for browsers further complicates the user experience andpresents a variety of problems in implementing a reliable DRM systemover the Web or other open networks.

VYOU.COM has developed a system for protecting intellectual property indocuments distributed over the Web. The system includes a softwareplug-in, to the user's Web browser. The plug-in includes a proprietaryrendering engine for the proprietary format in which documents arerepresented and transmitted. Accordingly, documents must be reformattedinto the proprietary format and the plug-in rendering engine for theappropriate final viewing format is used in place of the standardbrowser rendering engine. This arrangement requires the rendering enginefor each format must be developed. Therefore, this system is difficultto implement and loses the advantages of the Web as an openarchitecture.

The proliferation of the Web, and its usefulness in documentdistribution, makes it desirable to apply DRM features to Web browsersand other standard rendering engines without requiring the renderingengines to be rewritten. However, conventional DRM technologies are noteasily adapted to use with Web browsers and other standard renderingengines because they require proprietary formats and rendering engineswhich contradict the open architecture of the Web. The inability tocontrol application programs, such as Web browsers, independently fromtheir rendering engines has made it difficult to apply DRM features overdistribution networks.

Another roadblock to implementing DRM systems over the Web is the factthat often the fees paid for proprietary documents, particularly forlimited rights in proprietary documents are relatively small. Forexample, in many cases, the fees for limited rights in proprietarydocuments may be less that one dollar ($1.00) U.S. In such cases, theexpense associated with processing a credit card charge, includingaccess fees, transaction fees, and the like are relatively large ascompared to the entire document fee. For such relatively smalltransactions, often referred to as “micro-transactions,” the use of acredit card for the corresponding “micropayment”, i.e. relatively smallpayment, is not practical. Further, since each credit card transactionis processed as an individual charge, a customer purchasing a largevolume of documents in various transactions, will generate a largenumber of small transactions which is not efficient for credit cardtransactions.

Various proprietary solutions have been developed for handlingmicropayments, and other payments, over the Internet. For example,CyberCash™, Inc. and ePayment Systems™, Inc. each provide suchsolutions. Also, Intellicent™ provides a specific solution formicropayments. However, these solutions are not integrated in a DRMenvironment.

SUMMARY OF THE INVENTION

An aspect of the invention is a method and apparatus for managing use ofprotected content by providing a specific user interface to anapplication program used to render the content. The method comprisesidentifying a user interface description associated with content,building a specific user interface based on the user interfacedescription, and replacing the standard user interface of an applicationprogram used to render the content with the specific user interface.

BRIEF DESCRIPTION OF THE DRAWING

The invention is described through a preferred embodiment and theattached drawing in which:

FIG. 1 is a block diagram of a document distribution system utilizingDRM technology;

FIG. 2 is a schematic representation of a DRM system of the preferredembodiment;

FIG. 3 is a flowchart of a method of operation of the preferredembodiment for causing the server to respond only to a protected client;

FIG. 4 is a flowchart of a method of operation of the preferredembodiment for accessing protected content;

FIG. 5 is a flowchart of a method of operation of the preferredembodiment for installing a security module;

FIG. 6 is a flowchart of a method of operation of the preferredembodiment for inactivating a security module;

FIG. 7 is a flowchart of a method of operation of the preferredembodiment for facilitating authentication of a client for multipleservers;

FIG. 8 is a flowchart of a method of operation of the preferredembodiment for permitting a service to control the user interface of aclient;

FIG. 9 is a block diagram of content having references to user interfacecomponents;

FIG. 10 is a flowchart of a method of operation of the preferredembodiment for applying client-specific watermarks;

FIG. 11 is a flowchart of a method of operation of the preferredembodiment for aggegating transaction information;

FIG. 12 is a flowchart of a method of operation of the preferredembodiment for address obfuscation;

FIG. 13 is a flowchart of a method of operation of the preferredembodiment for using an asynchronous protocol for HTTP documenttransfer;

FIG. 14 is a flowchart of a method of operation of the preferredembodiment for dynamic certification of software;

FIG. 15 is a flowchart of a method of operation of the preferredembodiment for dynamic variable encryption;

FIG. 16 is a flowchart of a method of operation of the preferredembodiment for embedding security information in a document;

FIG. 17 is a flowchart of a method of operation of the preferredembodiment for determining usage rights based on a requesting URL;

FIG. 18 is a flowchart of a method of operation of the preferredembodiment for downloading necessary rendering applications; and

FIG. 19 is a flowchart of a method of operation of the preferredembodiment for time stamping validation tokens.

DETAILED DESCRIPTION

The invention is described below with reference to a preferredembodiment. It will be apparent that the invention can be embodied in awide variety of forms, some of which may be quite different from thoseof the disclosed embodiment. Consequently, the specific structural andfunctional details disclosed herein are merely representative and do notlimit the scope of the invention.

FIG. 1 is a block diagram of a model for a system for the electronicdistribution of digital documents. Author 110 creates original content112 and passes it to distributor 120 for distribution. Ordinarily,author 110 is the creator of the content. However, the term “author” asused herein can be the creator, owner, editor, or other entitycontrolling the content or an agent (e.g. a publisher) of one of thoseentities. Also author 110 may distribute documents directly, withoutinvolving another party such as distributor 120, and thus the author anddistributor may be the same entity. However, the division of functionsset forth in FIG. 1 is more efficient, as it allows author 110 toconcentrate on content creation and not the administrative functions ofdistribution. Moreover, such a breakdown facilitates economies of scaleby permitting distributor 120 to associate with a number of authors 110.The term “document”, as used herein, generally refers to any type ofcontent, such as text, audio, or other data, including any encryption,formatting, or the like. The term “content”, as used herein, generallyrefers to the underlying information of a document. However, these termsoverlap and thus are used interchangeably herein.

Distributor 120 distributes documents to user 130 upon request. In atypical electronic distribution model, the content is distributed as adocument in encrypted form. Distributor 120 encrypts the content with arandom key and then encrypts the random key with a public keycorresponding to user 130. Thus the encrypted document is customizedsolely for the particular user 130. User 130 is then able to use theirprivate key to unencrypt the random key and use it to unencrypt and viewthe document.

Payment for the document is passed from user 130 to distributor 120 byway of clearinghouse 150 which collects requests from user 130 and fromother users who wish to view a particular document. Clearinghouse 150also collects payment information, such as debit transactions, creditcard transactions, or other known electronic payment schemes, andforwards the collected payments as a payment batch to distributor 120.Of course, clearinghouse 150 may retain a share of the payment as a feefor the above-noted services. Distributor 120 may retain a portion ofthe batch payment from clearinghouse 150 for distribution services andforward a payment (for example royalties) to author 110. Distributor 120may await a bundle of user requests for a single document beforedistributing the document. In such a case, a single encrypted documentcan be generated for unencryption by all of the requesting users 130.

Each time user 130 requests (or uses) a document, an accounting messageis sent to audit server 140 which ensures that each request by user 130matches with a document sent by distributor 120. Accounting informationis received by audit server 140 directly from distributor 120. Anyinconsistencies are transmitted via a report to clearinghouse 150, whichcan then adjust the payment batches made to distributor 120 accordingly.This accounting scheme is present to reduce the possibility of fraud inelectronic document distribution and to handle any time-dependent usagepermissions that may result in charges that vary, depending on theduration or other extent of use. Audit server 140 and clearinghouse 150,in combination, can serve as transaction aggregator 160 which functionsto aggregate plural transactions over a period of time, and chargedistributor 120 in an appropriate manner to reduce the accountingoverhead of distributor 120. The model for electronic documentdistribution illustrated in FIG. 1 can be applied to the electronicdocument distribution system of the preferred embodiment disclosedherein. Further, content can include usage rights as described above.

FIG. 2 is a schematic representation of a computer architecture of adocument distribution system in accordance with a preferred embodimentof the invention. As noted above, the invention can be used inconnection with known models for effecting accounting and payment offees, such as use of a clearinghouse and an audit server. Further, theinvention can be used in connection with various commerce models.Accordingly, the apparatus for auditing distribution, effecting payment,and authoring a document is not described in detail herein and isomitted from the discussion of the preferred embodiment to simplifydescription thereof.

As illustrated in FIG. 2, digital content distribution system 200comprises distributor server 220, corresponding to distributor 120described above, and client computer 230, corresponding to user 130described above. Server 220 and client computer 230 can be generalpurpose computers programmed to accomplish the desired functions. Forexample, server 220 can be a standard server or workstation running theWindows NT™ operating system and including HTTP server software 226 suchas Apache™ or another HTTP server. Client 230 can be a personal computerrunning the Windows™ operating system. In the preferred embodiment,server 220 and client 230 are each coupled to communications network300, such as the Internet, or more specifically, the Web. Accordingly,client 230 includes browser 232 as a standard application program havinga rendering engine. Browser 232 can be any HTTP compliant browser, suchas Microsoft Internet Explorer™ or Netscape Navigator™. The phrase“standard application program”, as used herein, refers to anyapplication program designed to accomplish a task, such as documentcreation, viewing and editing, and having a rendering engine. Examplesof standard application programs include word processors, Web browsers,editors, viewers, spreadsheet programs, database programs, and the like.

Server 220 has a plurality of documents 222 stored thereon, in the formof Web pages, for distribution. Documents 222 can be stored in anencrypted format. The term “encrypted”, as used herein, refers to anymechanism by which accessibility of content is partially or completelyprohibited, such as by use of asymmetric or symmetric encryptionalgorithms, scrambling algorithms, or the like. Server 220 also includesdigital rights management module 224, in the form of software, forstoring and managing usage rights associated with particular ones ofdocuments 222, users, and/or payment amounts or other conditions. Otherfunctions of rights management module 224 are described in greaterdetail below. Distributor server 220 can be part of a server farm orother group of computers, which can also include distributor server 220′as illustrated in FIG. 2.

Client 230 also has user interface (UI) module 234 and connection module236 each in the form of software and each adapted to attach to browser232 without the need for modification of browser 232. For example, UImodule 234 and connection module 236 can be in the form of plug-ins,ActiveX controls, or in any form that allows attachment to the renderingengine of browser 232 without the need for modifying the code of browser232. Such attachment is described in greater detail below. Incombination, UI module 234 and connection module 236 constitute asecurity module which is described in detail below. While securitymodule 237 is illustrated as residing in client computer 230, it willbecome clear that security module 237 can include client side componentsand server side components. For example, DRM module 224 described belowcan be a server side component of security module 237.

Rights management module 224 is a server side component that can storelabels of usage rights and identify which rights are associated witheach document 222. The rights also can vary based on the identity of theuser requesting access to document 222, any payment made by the userthrough a clearinghouse or the like, and any other conditions. Forexample, the user may have the option of paying one fee to view document222 or a higher fee for viewing and printing the same document 222, asis well known. Rights management module 224 is also operative to deliverthe appropriate list of rights along with the document, viacommunications network 300, to connection module 236 of client 230 asdescribed below.

Connection module 236 can be a client side software component whichverifies the integrity of the environment of client 230 by verifyingthat UI module 234 is attached to browser 232, identifies the user ofclient 230, i.e. the person requesting content, retrieves the documentand the appropriate list of rights sent by rights management module 224,and in appropriate circumstances, unencrypts any retrieved documentsthat are encrypted and generates any necessary signatures and/or keys.UI module 234 can be a client side component that monitors requests fromthe user to access content of documents 222 and either grants or deniesthe request based on the list of rights retrieved by connection module236. Further, UI module 234 can disable specified functions of browser232 and the operating system of client 230 based on the list of rightsin the manner described below, by interfacing with the operating systemAPI and intercepting and redirecting commands for example. Connectionmodule 236 verifies that the industry standard rendering engine runningin the environment of client 230 has not been tampered with or otherwisecompromised in a way that may allow the user to access protected contentin a way that bypasses UI module 234.

The invention can be implemented in connection with known client/servernetworking architectures, such as the Web, without modifying obviating,or bypassing the standard client software, server software, andrendering engines. Rights management module 224 is installed in server220 along side the existing server software 226. As noted above, rightsmanagement module 224 identifies which rights are associated withdocuments 222 existing on server 220 or later stored on server 222. Forexample. Rights management module 224 can have a programmable database,lookup table or the like including the various rights associated witheach document 222 and other variables, such as the identity of the userand the payment made by the user, in a well known manner. Rightsmanagement module 224 further interfaces with the operating system APIof server 220 to cause server software 226 to only respond toconnections from client(s) 230 having the proper components of securitymodule 237, such as connection module 236 and UI module 234. Also,rights management module 224 serves as in interface with database 225described below.

For example, once rights management module 234 is installed theprocedure illustrated in FIG. 3 is accomplished. In step 302, a new DRMstart Web page, or other secure interface display, is created whichreferences UI module 234 and the existing server start Web page. In step304, the various Web pages of a Web site on server 220 can be placed ina directory having a random label or any unknown directory. In step 306,rights management module 224 is programmed to include a pointer to thisdirectory and, in step 308, rights management module 224 encrypts theURL of this directory. In step 310, the start DRM Web page is modifiedto reference UI module 235 which can instruct connection module 236 tounencrypt the encrypted URL to permit access to original start page andthe rest of the Web site. If client 230 does not have UI module 234 andconnection module 236, the URL cannot be unecrypted and thus the Website on server 220 cannot be accessed.

Alternatively, connection module 236 can generate a signature and sendthe signature to server 220 with any URL request to server 220. Accessto the Web site on server 220 will only be granted if the signature ispresent and valid. In this alternative, rights management module 224 caninclude code to validate the signature.

When a user of client computer 230 attempts to access server 220 havingrights management module 224, rights management module 224 verifies ifall required components of security module 237 UI module 234, such asare installed on client 230 as described above. If not, instructions inthe DRM start Web page, in the form of a java applet, ActiveX control,or the like, instruct browser 232 to download and install UI module 234in the manner described in greater detail below. Download can beaccomplished from server 220 or another server coupled to communicationsnetwork 300. Such download and installation can be accomplished in aknown manner using conventional mechanisms, and the user can be promptedto authorize installation and to enter other necessary information, suchas where to store the installation files. Connection module 236 can beimbedded in UI module 234 and downloaded and installed simultaneously orthrough a separate download and installation process. Of course, if UImodule 234 is detected as installed on server 230, the installation stepcan be skipped. If UI module 234 is not installed on client 230, and theuser does not authorize such installation, access to documents on server222 is prohibited, or limited only to documents specified as beingfreely distributable.

As noted above, UI module 234 and connection module 236 are in a form inwhich they can be attached to browser 232 without the need to modify thecode of browser 232. The term “attached” as used herein with respect tothe modules, refers to software modules that can be combined or coupledwith browser without modifying the code of browser 232. For example, UImodule 234 and connection module 236 are in the form of plug-ins, in thecase of Netscape Navigator™ or ActiveX Controls in the case of InternetExplorer™. The mechanisms for developing and installing such componentsare well known.

A procedure for accessing protected content, in the form of documents222, stored on server 220 is illustrated in FIG. 4. In step 402, the DRMstart Web page is accessed through its URL in a known manner. In step404, the DRM start Web page directs UI module 234 to the original startpage or pages referenced by the DRM start Web page using one of themethods described above. In step 406, UI module 234 creates anotherinstance of the rendering engine of browser 232, loads the originalstart Web page, and instructs the operating system to display the newinstance in a browser window, using known techniques. The new instanceis directed, by UI module 234, to retrieve content from server 220through connection module 236 in step 408. In other words, in thepreferred embodiment, UI module 234 intercepts commands from browser 232and redirects them through connection module 236. UI module 234 caninstruct the new instance to utilize a secure asynchronous protocolthrough connection module 236 as describe in greater detail below.Therefore, UI protection is validated and all user interface events, canbe intercepted and controlled in step 410. For example, when the userinitiates a “print” or “copy” command through the standard userinterface of browser 232, UI module 234 intercepts the request and onlypermits response if the set of rights received by connection module 236permits the requested function to be carried out.

More specifically, when connection module 236 receives a request fromthe rendering engine of browser 232, connection module 236 validatesthat the rendering engine is protected by UI module 234, i.e. UI module234 is attached, and that the rendering engine has not been tamperedwith or otherwise compromised. If so, connection module 236 permitsconnection to rights management module 224 of server 220 and negotiatespermission to retrieve the original start Web page on server 220 and theset of rights for the user for the Web page. Rights management module224 then initiates a connection between server software 226 of server220 and connection module 236 of client 230. The connection can beestablished using any protocol, such as HTTP or HTTPS or any otherstandard or proprietary connection protocol.

The requested document 222 is then retrieved and delivered to connectionmodule 236 which unencrypts document 222, if encrypted on server 220,and delivers the document in unencrypted form to the new instance of therendering engine of browser 232 along with the set of rights associatedwith the document. Once again, the contents of the set of rights may bedetermined based on the document, the user's identity, a payment made bythe user, or any other appropriate parameter. Connection module 236 thentransmits the set of rights to UI module 234 which limits the functionsavailable to the user based on the set of rights by controlling the newinstance of the rendering engine of browser 236 as described above.

The content of the document is now viewable in a window of browser 232as any other Web page would be. However, browser 232 does not havedirect access to the Web page of the document because browser 232 is“wrapped” by UI module 234 or other components of security module 237 aswill be described below. UI modules 234 prevents browser 232 fromperforming any prohibited functions outside of the scope of the set ofrights for the document.

The preferred embodiment utilizes a standard rendering engine of anapplication program, such as a browser, a word processor, or any otherapplication or display program. The preferred embodiment achieves thisby interfacing with the application and standing between the applicationand the document to control access to the document. Accordingly, aseparate proprietary rendering engine for each document format is notrequired. Further, any data format supported by the application will besupposed by the invention without modification. It can be seen that thepreferred embodiment permits DRM systems to be adapted to standards,such as TCP/IP and the use of browsers to render HTML. Further, thepreferred embodiment facilitates various functionality that permits DRMto be applied to systems in a manner that is transparent to the user.Several examples of methods of operation of document distribution system200 are described below.

In the first example, client computer 230 initially does not have allrequired components of security module 237 installed therein. Asillustrated in FIG. 5, client computer 230, makes a request ofdistributor server 220 for one or more documents 222 in step 502.Distributor server 220 analyzes the request and based on a lack ofsignature information within the request (indicating that components ofsecurity module 237 are not loaded in client computer 230), sends aresponse to client computer 230 to load the requisite components ofsecurity module 237 in step 504. As noted above, security module 237functions to enforce usage rights in client computer 230. The responsesent in step 504 is specific to the type of client requesting thecontent. If the client software on client computer 230 is a Web browser,for example, distributor server 220 will send a response that is a Webpage including an executable software component. For example, thesoftware component can be in a standard form such as Java Script orActive Server Pages. In addition the response, a Web page in thepreferred embodiment, can include a copy of the unsigned request forcontent sent in step 502.

Client computer 230 receives the Web page and executes the softwarecomponent that includes information about where to get the components ofsecurity module 237, in step 506, to request a copy of the components.Client computer 230 receives and installs the components of securitymodule 237 in step 508. Security module 237 is configured toautomatically begin to run in browser 232, using the mechanism describedabove for example. In step 510, security module 237 then reads the copyof the original request for content 222 contained in the Web page whichinvoked security component 237 and resubmit the request to distributorserver 220 with a digital security signature. In step 512, distributorserver 220 receives the signed request and validates the signature onthe request. Because this request is properly signed by security module237, distributor server 220 delivers the document 222 to security module237 installed on client computer 230 for rendering by browser 232 inaccordance with usage rights and conditions associated with the contentof document 222. The method illustrated in FIG. 5 provides forauto-engaging security control to seamlessly and transparently providethe client with the software that the user needs to render content 222in a secure manner. Security module 237 can include a software agentthat is operative to analyze any rendering engine or other components ofclient computer 230, in step 508, to validate that the clientenvironment is secure. Security module 237 can resubmit the request, instep 510, after such validation.

FIG. 6 illustrates another example of a method of operation of thepreferred embodiment. In step 602, security module 237 is directed toretrieve a document 222 from distributor server 220 server. In thisexample, document 222 is “clear content,” i.e., is not encrypted orotherwise obscured or limited and does not have any use restrictions.Document 222 is returned by server 220 to security module 237 in step604. Because document 222 is not signed, or encrypted, or otherwisemarked as content that needs to be handled by security module 237,security module 237 recognizes that it is no longer required. In step606, security module 237 notifies browser 232 that browser 232 shouldrequest document 222 directly by sending the original request forcontent to server 220. Security module 237 then removes itself as arunning component, i.e., inactivates, in step 608 to preserve resourcesof client computer 230. In step 610, browser 232 then resubmits therequest for document 222 that was originally sent by the security module237. Distributor server 220 then delivers documents 222 directly tobrowser 232 in step 612.

In order to maintain security and enforce usage rights, all requests forcontent are initially made through security module 237. However, whenthe request returns content that does not require security, securitymodule 237 becomes a potential liability because it utilizes computerresources. In this example, if security component 237 is not needed, itis removed from a running state.

System 200 can use PKI encryption technology or any other encryption,ciphering, or watermarking technology. Of course, each technologyrequires that a client making a request for content be identified as anauthorized user. A digital certificate or signature can be used foridentification purposes. In other words, an attachment to an electronicmessage used for identification purposes is sent with a message. Themost common use of a digital certificate or signature is to verify thata user sending a message is who he or she claims to be, and to providethe receiver with the means to encode a reply, e.g., an encryption key.An individual wishing to send an encrypted message can apply for adigital certificate from a Certificate Authority (CA). The CA issues anencrypted digital certificate containing the applicant's public key anda variety of other identification information. The CA makes its ownpublic key readily available, through the Internet for example. Therecipient of an encrypted message uses the CA's public key to decode thedigital certificate attached to the message, verifies it as issued bythe CA and then obtains the sender's public key and identificationinformation held within the certificate. With this information, therecipient can send an encrypted reply. The most widely used standard fordigital certificates is X.509.

This identification process can be cumbersome when repeated at eachserver from which content is requested. FIG. 7 illustrates anotherexample of a method of operation of the preferred embodiment in whichthe identification procedure at plural servers is expedited.

As illustrated in FIG. 7, client computer 230 requests document 222 fromdistributor server 220 in step 702. Assuming that PKI encryption schemesare used, the request can be in the form of “PrivateClient[request]” inwhich the request is encrypted with a private key of client computer230. Distributor server 220 looks at the signature of the request andrecognizes that the request is not from an authenticated client andgenerates a unique “challenge” token which is returned to clientcomputer 230 in step 704. In the preferred embodiment, the challengetoken can be in the form of “PrivateServer[PrivateClient[request]]” inwhich the original encrypted request is encrypted again using theprivate key of distributor server 220.

Client computer 230 answers the challenge taken by transforming thechallenge in a unique way, i.e., signing the challenge token, in step706. For example the transformation can be in the form of encryption ofthe challenge token with the public key of distributor server 220. Insuch a case, the transformation will be in the form of[PublicClient[PrivateServer[PrivateClient[request]]].” Client computer230 then resubmits the request to the distributor server 220 with thetransformed challenge token in step 708. Distributor server 220establishes authentication with the client by recognizing thetransformation. i.e. recognizing the challenge token as its own, andreturns the requested document 222 in step 710.

In many cases, distributor server 220 is part of a server farm or otherset of related computers as noted above. Therefore, there is noguarantee that the server that gets the next request for this sessionwill in fact be the same server that generated the “challenge” token.For example, the next session request may be received by distributorserver 220′. When client computer 230 sends another request reusing thesame challenge token and the request is received by distributor server220′, in step 712, distributor server 220′ looks for the signature ofthe challenge token, and finds that the signature belongs to distributorserver 220, in step 714. Since distributor server 220 has a trustedrelationship with distributor server 220′, distributor server 220′ willhonor the challenge token of distributor server 220. In particular,distributor server 220′ evaluates the transformation of the challengetoken performed by the client and authenticates the client byidentifying server 220 as the creator of the challenge token. In step716, content 222′ is delivered from distributor server 220′ to clientcomputer 230.

In this method of operation a token supported by other related serversis honored by a server receiving a request. In order to simplify theprocess, keys are not exchanged again. The approval of a previous keyexchange with a related server is used for any other server in a groupof related servers to speed up the process of authentication.

As noted above, the use of a standard rendering engine presentssignificant complications for DRM systems. For example, when using abrowser as the rendering engine, the standard user interface includescopy and print commands and other commands not necessarily compatiblewith DRM systems. It is known to disable such commands in which casemost GUIs, such as the Windows GUI, will shadow the menu selectionscorresponding to disabled commands. However, this is often confusing andnot ascetically pleasing. Further, it may be desirable to providecontent specific menu selections, such as choices of usage rights andconditions for exercise thereof, such as fees to be paid. Further, acontent vendor may want to present a proprietary branded user interfaceor a user interface that is consistent with other vendors. Also, it maybe desirable to highlight menu selections, such as a print button, undercertain circumstances.

FIG. 8 illustrates a method of operation of the preferred embodimentwhich permits content specific toolbars to be displayed as the userinterface of browser 232. Documents 222 are stored on distributor server220, as described above, in a form compatible with the renderingapplication, a Web page in the preferred embodiment. Documents 222 areillustrated in detail in FIG. 9 and include reference A to softwarecomponent 220 a and reference B to description of a browser toolbar andUI 220 b. Software component 220 a can be in the form of a Java applet,an Active X control, or the like. As the content is rendered, thereference to the software component is identified by the browser i.e.ActiveX Control, Java applet.

Referring to FIG. 8, browser 232 requests document 222 in step 802.Browser 232 attempts to render document 222 and follows reference A tothereby execute software component 220 a in step 804. Software component220 a then looks at content 222 that invoked it and identifies referenceB to description of toolbar and UI 220 b in step 806. Software component220 a then is operative to build a platform/browser specific toolbar andUI based on description 220 b in step 808. In step 810, softwarecomponent 220 a removes or hides the standard browser UI and tool barand replaces them with those built in step 808. This method of operationpermits the Web site (distributor for server 220 in this case) todictate the navigation's motif, look, and appearance and thus tailor theuser's browser to the site, customizing buttons, colors, patterns,animations, menus, and tool bars.

FIG. 10 illustrates another manner of operation of the preferredembodiment in which a client-specific, or even instance specific,watermark can be applied to content for security and tracking purposes.The concept of digital “watermarking” is well known generally and allowscontent owners to imbed information within graphics and audio files thatcan be used to identify the owner's rights to these works. The term“digital watermark” is derived from the traditional watermarks thatexist in high-quality letterhead and certain currency. Traditionalwatermarks typically are not apparent to the reader, but, when held tothe light, reveal the name or logo of the paper's manufacturer or theentity using the letterhead. Similarly, digital watermarks also servethe purposes of identifying quality and assuring authenticity. A graphicor audio file bearing a digital watermark can contain informationrelating to the content owner or other information. Digital watermarksmay be only perceptible under certain conditions, such as when contentis printed in an unauthorized manner. In graphic images, for example,digital watermarks alter the image to provide digital informationsupplied by the party who imbedded the watermark. The watermarks may beviewed with stand-alone or plug-in software and can reveal, for example,a unique identification code that can be traced to the copyright owneror more complete copyright ownership information.

As illustrated in FIG. 10, client computer 230 requests document 222from distributor server 220 over communications channel 300 in step1002. Distributor server 220 delivers document 222 to security module237 in step 1004. Note that document 222, as delivered to securitymodule 237, may or may not have a watermark embedded therein. In step1006, security module 237 delivers document 222 to an instance of therendering engine, browser 232 in the preferred embodiment, for renderingin the manner described above. Security module 237 then usesinstance-specific information relating to the instance of the renderingengine used to render content 222 to apply a client-specific watermarkto the window that the instance of the rendering engine uses in step1008. The client-specific watermark can be applied using any techniquesor algorithms for watermarking. Also, the client-specific watermark canbe applied in addition to an existing watermark. The client-specificwatermark data can be stored or generated in any manner.

In either case, because the watermark is applied on the client, it canbe unique to that client, and thus be traceable. Distributor server 220can deliver identical document 222 to all clients (thus minimizingserver side performance impact). The client then applies a uniquewatermark using, for example, translucent windows to the image. If theconsumer of the content then uses screen capture or another unauthorizedmechanism to capture the content, the captured content is thenwatermarked with an ID that is unique to that user for tracking andenforcement purposes.

FIG. 11 illustrates a manner of use of the preferred embodiment in whichtransaction payments are easily aggregated. In step 1102 client computer230, prior to installation of the requisite components of securitymodule 237, requests document 222 from distributor server 220. In step1104, distributor server 220 then informs client computer 230 thatdocument 222 is protected and client computer 230 needs to have securitymodule 237 to render document 222, and where security module 237 can beacquired. In this case, security module 237 can be acquired from acomputer associated with transaction aggregator 160 (See FIG. 1). Instep 1106, client computer 230 requests the requisite components ofsecurity module security module 237 from transaction aggregator 160 byopening a session with the computer associated with transactionaggregator 160. In step 1108, transaction aggregator 160 requests andcollects various user information including billing information and thelike for example in a conventional manner.

Transaction aggregator 160 generates a unique security module 237 with ahidden unique public private pair or other indicia of the identity ofclient computer 230, and returns security module 237 to client computer230 in step 1110. Security module 237 creates a protected instance ofbrowser 232, or other 3^(rd) party rendering application, enforcesaccess protection around it, and instructs it to retrieve and renderprotected content 222 from distributor server 220 in step 1112.Distributor server 220 recognizes document 222 is being requested by arendering engine that has been protected with security module 237. Andreturns document 222.

The protected rendering application, e.g. browser 232 with securitymodule 237 attached, informs security module 237 that it is about torender document 222. In step 1114, security module 237 analyzes what thedigital rights are associated with document 222, and records anappropriate charge back to transaction aggregator 160. Transactionaggregator 160 tracks many small transactions performed against manyforms of content accessed by this instance of a public private key, thenaggregates them into a single charge periodically to a financialinstitution or other party associated with the indicia in securitymodule 237.

The method of FIG. 11 permits a user to log on to a new Web site toinitiate a transaction. If the user's information is already on file ata trusted site (such as transaction aggregator 160) the new Web siteverifies the user through the trusted site. The trusted site reconcilesall of the transactions and sends the results to the appropriate entityperiodically, monthly for example. Accordingly, the burden of handlingthe transactions (often of small denominations) is shifted from thedistributor or credit agency to the aggregator, which reduces theoverall cost of transactions.

The new Web site does not have to obtain the detailed information of theuser, which reduces concerns over privacy issues. In addition, thelog-in process for the new Web site is simplified. Because the Websiteuses only an anonymous ID sent to the trusted site, and only the trustedsite has the user's personal and credit information, the user'sinformation is protected from the new Website that the user istransacting with.

Another method of operation of the preferred embodiment utilizesdirectory obfuscation for security without the need for a server sideexecutable component. As illustrated in FIG. 12, the content owner, orother party having an interest in documents 222 creates a subdirectoryon distributor server 220 with a random name, or other difficult name todiscover, to serve as a secure location of documents 222 in step 1202.The interested party then creates a Webpage which has a reference tosecurity module 237 and an encrypted form of the new secure location ofthe documents 222 in step 1204. The protected documents 222 are thenreplaced with the Web page, in step 1206, and protected documents 222are moved into the secure directory.

In step 1208, client computer 230 issues a request to retrieve adocument 222 from the original directory in the manner described above.The security Webpage which has the secret location of the contentencrypted in it is returned instead of the requested document in step1210. Security module 237 decrypts the location of the contentreferenced by the Web page and requests document 222 from the securelocation in step 1212. The content is delivered to security module 237which creates an instance of a protected rendering engine, e.g. browser232 in the preferred embodiment, and renders document 222 in step 1214.

The method of operation described above does not require a server sideexecutable and thus is an inexpensive way to provide adequate, while notnecessarily maximum, security. In this example, the content is stored ina location having and address determined by a random number (or apseudo-random number), for security purposes. Then, when the userinitiates a transaction, the user is presented with an HTML page havingthe location in an encrypted form. The security component decrypts thelocation and the client never discovers the location.

FIG. 13 illustrates another method of operation of the preferredembodiment which utilizes relative addressing for security. In step 1302web browser 232 of client computer 230 requests content from distributorserver 220. Distributor server 220 recognizes that the content requestis not coming from an appropriate security module 237 (by the lack of aproper signature for example), so it instructs client computer 230 toload the requisite components of security module 237 in step 1304. Instep 1306, security module 237 spawns a child HTML rendering engine,i.e. instance of browser 232, inside the existing instance of browser232 so that it can have full control of the child HTML rendering engine.Security module 237 then instructs the child instance to retrievecontent through an asynchronous protocol installed in security module237 instead of through ordinary HTTP protocol and addressing in step1308. For example, the asynchronous protocol can be HTML with Active Xcontrols embedded therein to establish a secure authenticatedcommunication channel. The asynchronous protocol can direct browser 232to retrieve content through another Web site that includes filteringtechnology to prevent access from unwanted or unauthorized users.Document 222 is rendered in step 1310.

For example, the asynchronous protocol can send the address of the userto a third party for verification that the user is wanted andauthorized. The asynchronous protocol can cause the child instance ofbrowser 232 can request the top level HTML page via a designated secureWeb site. After the top level page loads, the child instance can use anaddress prefix to retrieve all of the component parts of the page.Unprotected content can be retrieved via standard HTTP.

Generally, security is handed to HTML for rendering. However, in thisexample, content is retrieved using a proprietary asynchronous protocol.Therefore, a single instance of an HTML rendering engine can be used to“pull” compound pieces of content. As an example, standard HTMLrendering can be used to access a start Web page containing an Active Xcontrol in it. The control spawns a child rendering engine whichretrieves content through a specified server, which in turn accesses theserver side, which includes the filtering technology or the like. Notethat a Web page (a compound document) has references to other files andimages. Conventionally, only the top level (HTML page) is protected, andthe references are not protected. However, in this example, sincerequests are handled through a secured server, both the top level andthe references are secure.

FIG. 14 illustrates another method of operation of the preferredembodiment. This method provides security by prohibiting the loading ofcode, such as plug-ins and Dynamic Link Libraries (DLLs), into therendering engine unless the code is certified as not compromisingsecurity. This method recognizes that certification can be a dynamicprocess that should permit users to use certified software immediatelyupon certification.

In step 1402 security module 237 of client computer 230 loads aninstance of a rendering application, browser 232 in the preferredembodiment. Browser 232 requests to load a third party add in program,such as DLL, in step 1404. Security module 237 intercepts the requestand querys local database 225 including a list of trusted certifiedthird party add in programs in step 1406. If security module 237 doesnot find the third party program that is attempting to load, securitymodule 237 contacts a trusted server to update its database of trustedthird party programs that are certified in step 1408. If the third partyprogram is found in the updated list, security module 237 permits theloading of the third party program into the rendering engine in step1410. If the determination in step 1406 is that the program is certifiedby being listed in database 225, the method goes directly to step 1410.If the determination in step 1408 is that the program is not in theupdated database as being certified, loading is prohibited in step 1412.

Whenever the rendering application wants to load any executable code, itshould be approved, i.e., certified, to avoid compromising security. Ifat the time of shipment of the security component a third party productis not ready for certification, it cannot be included in the approvedlist in the security module. If the program is approved later, thesignature of the program will be compared to a list updated by loggingonto to a server having and updated certification database, data base225 for example.

FIG. 15 illustrates a method of operation of the preferred embodimentwhich is well suited for the transfer of content in the form of video orother large files. It is known to encrypt only portions of data toreduce overhead and data transfer speed while still providing a level ofsecurity. However, in the method illustrated in FIG. 15, the percentageof encryption of a data stream is adaptive based on network latency,connection speed and other factors. In step 1502, document 222 isrequested by client computer 230. Distributor server 220 determines whatpercentage of encryption to use by examining a database, usage rights,or other indication of encryption associated with document 222 in step1504. Such information can be stored in digital rights managers module2. For example, the indication of encryption can specify that encryptionbe greater than a specified percentage or in a range of specifiedpercentages.

In step 1506, distributor server 220 monitors various conditions relatedto data transfer, such as the files size of document 222, networklatency, communication speed, and the like in a known manner. In step1508, distributor server 220 encrypts portions of document 222 based onthe conditions monitored in step 1506 and the encryption amountdetermined in step 1504. Steps 1506 and 1508 are conducted continuouslyor iteratively until all of document 222 has been transferred. In step1510, security module 237 decrypts the content and delivers it to therendering application, i.e. browser 232 in the preferred embodiment.

A variable portion (percentage) of a data stream can be encrypted.Content data can be divided by time intervals or based on the byte size.For example, 10 bytes encrypted, and 90 bytes not-encrypted. Thepercentage of encryption can be adaptive. That is, depending on the datafile size and other conditions, at different times, the percentage ofencryption can vary between values specified to speed up the process.

It is known to embed signatures and other security information in thebody of an HTTP document. However, such a practice requires specialsecurity tags and is difficult to manage since the security informationmust be parsed out of the document. However, the method of operation ofthe preferred embodiment illustrated in FIG. 16 simplifies thisoperation by using only the header of an HTML document for conveyingsecurity information.

In step 1602, browser 232 that is regulated by security module 237requests document 222 from distributor server 220 and security module237 opens up a standard HTTP or HTTPS connection to distributor server220. In step 1604, distributor server 220, functioning as a standardHTTP server, retrieves or builds document 222 for downloading. Inparticular, digital rights management module 224 or another securitymodule component of distributor server 220 authenticates the requestingclient by analyzing security information embedded in the headers of theHTTP request and builds a standard HTTP reply.

In step 1606, distributor server 220 inserts security information intothe headers of the HTTP reply. For example, the security information,such as a signature can be an attribute of the <Header> tag in an HTMLdocument as set forth below:

<Header> signature=13490680486724869 MY BOOK <Header>

In the example above, the title of the HTML page is “MY BOOK” which willbe rendered in accordance with standard HTML rules. The signature is anumber as an attribute of the header and will not be rendered but can beculled for security purposes. In step 1608, the reply is sent tosecurity module 237 of client computer 230. In step 1610, securitymodule 237 analyzes the security information in the reply header andpasses content of document 222 to browser 232 for rendering inaccordance with the usage rights described by or associated with thesecurity information.

Since all of the security information is contained in the header, theresulting DRM system is less intrusive and easier to manage. Also, a newsecurity tag schema or other specification is not necessary. Thesecurity component need only know to look in the header to get securityinformation.

Often content and usage rights are dynamic. For example, the content maychange over time and the usage rights may change over time and may bedependent on where the request for content comes from. For example, acompany may want to let an employee print or save a document if thedocument is requested from an on-site, or otherwise secure, computer.However, the same employee requesting the same document from home mayonly be permitted to view the document. FIG. 17 illustrates a method ofuse of the preferred embodiment that provides both address and URLfiltering to address these issues.

In step 1702, client computer 230 having security module 237, requestssecure document 222. In step 1704, distributor server 220 gathersinformation from either static or dynamic sources of content 222 andbuilds the response in a known manner. After the response has beenbuilt, a server side component of security module 237 accesses adatabase 225 that maps regular expressions of URL's to usage rights instep 1706. Server side component of security module 237 inserts therights associated with the reply based on the URL of the request byselecting the rights corresponding to the URL in database 225 in step1708. The reply is then sent to client computer 230 for rendering of therequested content 222 in accordance with the inserted usage rights undercontrol of client side component of security module 237.

Since both URL addressing and directory addressing are used, dynamiccontent and content that is best identified by incoming request URL'scan be handled appropriately. Directories are filtered in order toprovide a high level of confidence that content stored on thedistributor server 220 as a file cannot be delivered to an unauthorizeduser no matter what URL is used to reach the file stored on the server.By using both types of filters, the content owner has flexibility indetermining what content should be protected and to what degree.Further, putting security content in the header of an HTML documentpermits dynamic content to be handled easily because the body of thecontent does not need to be modified for security and thus permitsdynamic content to be used to build a document on the fly.

Another problem often encountered in rendering content, particularlywhen distributing content over the Internet or other networks, is thatthe user may not always have the proper rendering application. Forexample, when downloading a PDF file, content providers will often warnthe user that Adobe Acrobat Reader™ is required and may even provide alink to download the software. If the user does not download thesoftware, they cannot render the content. However, downloading thesoftware requires significant action on the part of the viewer, such asclicking on the link, choosing a directory for download, executing theinstallation software, and the like. In many cases, the user will choosenot to download the content to avoid the cumbersome process ofinstalling the proper rendering application. In DRM systems, the needfor multiple rendering applications raises security issues if thesecurity component is not attached to a newly installed renderingapplication.

FIG. 18 illustrates a manner of use for providing the proper renderingapplications in a manner that is transparent to the user. In step 1802,client computer 230 requests document 222 that is of a file format thatcannot be rendered by browser 232. In step 1804, document 222 ispackaged as a file of the same format but is “disguised” as an HTMLfile. For example, the Windows™ operating system identifies file typesby file extension. In such a case, the file, for example a PDF file, canbe named with an “HTM” extension to be identified as an HTML file byclient computer 230.

In step 1806, the file is downloaded to client computer 230 and the user“opens” the file which client computer 230 recognizes as an HTML file.Accordingly, browser 232 is launched as the default HTML viewer. In step1808, browser 232 begins to render the HTML and finds a reference to anembedded application, like an ActiveX control or Java applet. Thebrowser embedded application causes 232 to check and finds that thereferenced application is not installed on client computer 230 in step1810. The browser follows the reference in the file to download theapplication in step 1812 and the application is installed on clientcomputer 230 and attached to security module 237 as described above. Theapplication, now used as the rendering application is directed bysecurity module 237 to retrieve the content from within the HTML fileand render the content in step 1814.

The drawback of distributing a new file type extension is that if theuser receives one of your data files and there is no registeredapplication to handle the request, then the user cannot continue workingwith the content or must manually install a new application. However, ifthe new file type is packaged inside an HTML file the Web browser thenloads the HTML file and automatically finds the code (JavaScripts,etc.). If the code sees a registered application on the client platformit passes the contained data to that client application. If it does notfind an application to handle the data type, it calls upon the browserto navigate to a site that downloads the appropriate renderingapplication.

Another security issue when distributing content over a network, such asthe Internet, is the possibility that hackers will intercept messagesand “crack” encryption routines to obtain access to protected content.However, circumventing encryption often requires a relatively great dealof time (several seconds for example) because of the need to executecomplex software algorithms or generate random numbers. FIG. 19illustrates a method of operation of the preferred embodiment in whichthe risk of encryption circumvention is reduced by creating tokens thatexpire after short period so time.

In step 1902, client computer requests secure content 222. Assuming thata server side security component of security module 237 has notauthenticated client computer 230, distributor server 120 generates achallenge token, that is time stamped, in step 1904. Client computer 230receives the token and uses its non-unique public key private key pairto add a request and sign it in a known manner in step 1906 and returnsthe signed token to distributor server 220. Upon receipt of the signedtoken, distributor server 220 verifies the signature of client computer230 and checks to see when the token was generated by examining the timestamp in step 1908. If the token was generated more than a predeterminedtime period, 0.5 seconds for example, before being received in a signedfashion, the token is no longer valid and access to content 222 will bedenied, in step 1910, even if the signature is otherwise correct.

The time stamp can indicate how long the signature is valid (usually avery short time that permits proper signature but does not permitencryption circumvention) or the time that the signature was created. Ifan unauthorized party intercepts the message, and tries to imitate themessage at a later time, then the signature will have expired and willnot be valid.

The invention can be implemented over any type of communicationsNetwork, such as the Internet, a local area network (LAN), a wide areanetwork (WAN), direct computer connections, or the like, using any typeof communication hardware and protocols. Any type of hardware orcombination of hardware can be used for the various clients and servers.Accordingly, the terms “client” and “server” as used herein, can referto any type of computing device or data terminal, such as a personalcomputer, a portable computer, a dumb terminal, a thin client, a handheld device, a wireless phone, or any combination of such devices. Thevarious clients and servers can be a single computer at a singlelocation or multiple computers at a single or multiple locations. Forexample a server may be comprised of a plurality of redundant computersdisposed in co-location facilities at various locations to facilitatescalability. There can be any number of clients and any number ofservers. The client can physically be located on the same hardware asthe server.

Any appropriate server or client software can be used and anycommunication protocols can be used. Communication can be accomplishedover electric cable, fiber optic cable, or any other cable, or in awireless manner using radio frequency, infrared, or other technologies.The various information can be stored in any format and thus the term“database” as used herein refers to any collection of information suchas a database file, a lookup table, or the like. The documents can be ofany type and can contain any type of content, such as text, audioinformation, video information, or combinations of plural types ofcontent. The portions of the invention described above that aredescribed as software components could be implemented as hardware.Moreover, while certain functional blocks are described herein asseparate and independent from each other, these functional blocks can beconsolidated and performed on a single general-purpose computer, orfurther broken down into sub-functions as recognized in the art. The setof rights can be one or more rights or rules governing use of thedocument, can be in any appropriate form, and can be based on variousparameters such as the document type, the user's identity, a payment bythe user, and the like. The various software modules can be located onthe client or the server. For example, the security module can includeone or plural components on the server side and/or on the client side asappropriate to accomplish the various functions disclosed above.

While a preferred embodiment of the invention has been described indetail above, it should be recognized that other forms, alternatives,modifications, versions and variations of the invention are equallyoperative and would be apparent to those skilled in the art. Thedisclosure is not intended to limit the invention to any particularembodiment, and is intended to embrace all such forms, alternatives,modifications, versions and variations. Accordingly, the true scope ofthe invention is defined by the appended claims and legal equivalents.

What is claimed is:
 1. A computer-implemented method executed by one ormore computing devices for utilizing content, the method comprising:rendering, by at least one of the one or more computing devices, contentusing a rendering application, the rendering application having astandard user interface; building, by at least one of the one or morecomputing devices, a content specific user interface; hiding, by atleast one of the one or more computing devices, the standard userinterface of the rendering application; and enabling, by at least one ofthe one or more computing devices, the content specific user interfacefor use by the rendering application while the content is being renderedand hiding the standard user interface while the content is beingrendered.
 2. At least one non-transitory computer-readable mediumstoring computer-readable instructions that, when executed by one ormore computing devices, cause at least one of the one or more computingdevices to: render content using a rendering application, the renderingapplication having a standard user interface; build a content specificuser interface; hide the standard user interface of the renderingapplication; and enable the content specific user interface for use bythe rendering application while the content is being rendered and hidingthe standard user interface while the content is being rendered.
 3. Anapparatus for enhancing use of content, the apparatus comprising: one ormore processors; and one or more memories operatively coupled to atleast one of the one or more processors and having instructions storedthereon that, when executed by at least one of the one or moreprocessors, cause at least one of the one or more processors to: rendercontent using a rendering application, the rendering application havinga standard user interface; build a content specific user interface; hidethe standard user interface of the rendering application; and enable thecontent specific user interface for use by the rendering applicationwhile the content is being rendered and hiding the standard userinterface while the content is being rendered.